4.5 Configure server signing certificates
To increase the level of security, MyID digitally signs some of the data objects that are written to the smart card:
-
CHUID (Card Holder Unique ID)
-
CBEFF (Biometric fingerprint data)
-
Security Object
The server can either use a single certificate to sign the data objects or a separate certificate can be configured for each object.
You can also configure MyID to use multiple signing certificates for the same type of data object – for example, if you have both PIV and PIV-I cards in circulation. For more information, contact customer support, quoting reference SUP-118.
FIPS 201 requires that each PIV card issuance is signed by a certificate issued in accordance with the X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework.
Note: For PIV compliance, this certificate must be protected by an HSM.
The signing certificate must:
-
Use SHA256 in the digestAlgorithm of the SignerInfo.
-
Use SHA256 in the AlgorithmIdentifier of the signature.
-
Be issued using the CSP or KSP of the HSM for key generation.
-
Be issued to the MyID COM+ account that is configured to run the MyID server components.
-
Use an RSA key – ECC is not supported.
Note: By default, MyID uses a hash algorithm of SHA256 for SCEP signing. The certificate that you use for signing must therefore have been produced using a KSP or CSP that supports SHA256; some older CSPs (for example, the Microsoft Strong Cryptographic Provider) do not support SHA256; the Microsoft Enhanced RSA and AES Cryptographic Provider does support SHA256, however.
For full FIPS 201 card issuances, the certificate must contain an extended key usage attribute of:
-
id-PIV-content-signing (2.16.840.1.101.3.6.7)
For PIV-I, the certificate must contain:
-
id-fpki-certpcy-pivi-contentSigning (2.16.840.1.101.3.2.1.3.20)
-
id-fpki-pivi-content-signing (2.16.840.1.101.3.8.7)
The signing certificate must not require any user intervention when signing:
-
Do not set the private key as User Protected; this requires a PIN entry dialog during signing.
-
If the key is protected by an HSM, do not configure the key to launch a PIN entry dialog. For an Entrust nShield HSM, the nShield CSP must not be configured to protect the private key with an operator card set that requires PIN entry. For nShield HSMs, the content signer certificate can be protected either by the module, or by an operator card set without PIN.
Note: You must configure the server signing certificates on the server prior to issuing PIV-compliant smart cards.
Refer to the FIPS 201 documentation for additional requirements relating to the PIV content signing certificate.
Before MyID can use a certificate to sign objects, the certificate must be available to the account used to run the MyID components.
Note: For PIV and PIV-I, you must use SHA256 for the PIV server hash algorithm; see section 4.6, Configuring the PIV server hash algorithm for details. You must make sure that the CSP you use to issue the certificate supports SHA256.
To configure the signing certificate in the MyID registry:
- On the MyID application server, log on using the MyID COM+ account.
-
Request a certificate that will be protected either by CAPI (Cryptographic Service Provider) or by CNG (Key Storage Provider).
You can issue a certificate from any certificate authority as long as it is available to CAPI or CNG.
Note: Do not enable strong private key protection on the certificate, as this will prevent processing of the request by the MyID account.
-
Once the certificate has been generated, install and save it as a .cer file (either Base64/PEM or binary format). You must save it in a location accessible to the MyID application, so save it to the Components folder within the MyID installation folder.
Note: You may need administrative privileges to save files to this area.
-
Enter the filename of the certificate in the system registry.
- From the Start menu, click Run and type regedit in the dialog displayed. Click OK.
-
Navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Intercede\Edefice\PIV
-
Set the value of the following keys to the full path of the certificate:
-
CBEFFSigningCertificate
-
CHUIDSigningCertificate
-
SecurityObjectSigningCertificate
-
Note: The server signing certificate will expire. Once the lifetime of issued cards goes beyond the expiration date of the server signing certificate, the issued card is no longer valid.
This means that the date at which the server signing certificate must be renewed depends not only on the expiration date of the server signing certificate, but also the intended card lifetime of the cards being issued.
To prevent a situation where the server signing certificate is not valid for the lifetime of the issued certificate, you must set up a procedure to ensure that the server signing certificate is manually renewed before issuing cards that have an expiration date that may exceed the expiration date of the server signing certificate.
Note: For details of setting up the CVC signing certificate for OPACITY, see the Setting up the CVC signing certificate section in the Smart Card Integration Guide.
4.5.1 Troubleshooting the content signing certificate
If you have made any mistakes in setting up the configuration for the content signing certificate (for example, omitting the path from the registry) you may see an error similar to the following when attempting to issue a card:
Data Model failed validation
If you see an error like this, check that you have configured the signing certificate correctly.